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Abstract 



/-*-\ We present iSAPP (Imperative Static Analyser for Probabilistic Polynomial Time), a complexity 

t-H verifier tool that is sound and extensionally complete for the Probabilistic Polynomial Time (PP) 

complexity class. iSAPP works on an imperative programming language for stack machines. The 

certificate of polynomiality can be built in polytime, with respect to the number of stacks used. 

U 
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Q 1 Introduction 

One of the crucial problem in program analysis is to understand how much time it takes a 
program to complete its run. Having a bound on running time or on space consumption is 
really useful, specially in fields of information technology working with limited computing 

_^ power. Solving this problem for every program is well known to be undccidable. The best 

t> we can do is to create an analyser for a particular complexity class able to say "y es '\ "no", 

or "don't know". Creating such an analyser can be quite easy: the one saying every time 

fvi "don't know" is a static complexity analyser. The most important thing is to create one 

(*C) that answers "don't know" the minimum number of time as possible. 

^+ We try to combine this problem with techniques derived from Implicit Computational 

Complexity (ICC). Such research field combines computational complexity with mathemat- 
ical logic, in order to give machine independent characterisations of complexity classes. 
• • ICC has been successfully applied to various complexity classes such as FP [H [TTJ H], 

.^ PSPACE P2], LOGSPACE 0. 

ICC systems usually work by restricting the constructions allowed in a program. This de 
facto creates a small programming language whose programs all share a given complexity 
property (such as computing in polynomial time) . ICC systems are normally extensionally 
complete: for each function computable within the given complexity bound, there exists 
one program in the system computing this function. They also aim at intentional com- 
pleteness: each program computing within the bound should be recognised by the system. 
Full intentional completeness, however, is undecidable and ICC systems try to capture as 
many programs as possible (that is, answer "don't know" as little time as possible). 

Having an ICC system characterising a complexity class C is a good starting point for 
developing a static complexity analyser. There is a large literature on static analysers for 
complexity bounds. We develop an analysis recalling methods from [2JE1QZII- Comparat- 
ively to these approaches our system works with a more concrete language of stacks, where 
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variables, constants and commands are defined; we are also sound and complete with respect 
to the Probabilistic Polynomial time complexity class (PP) [7J. 

We introduce a probabilistic variation of the Loop language. Randomised computations 
arc nowadays widely used and most of efficient algorithms are written using stochastic 
information. There are several probabilistic complexity classes and BPP (which stands 
for Bounded-error Probabilistic Polytime) [7] is considered close to the informal notion of 
feasibility. Our work would be a first step into the direction of being able to capture real 
feasible programs solving problems in BPP (BPP C PP) [7J. 

Similar work has been done in [B] with characterisation of complexity class PP; This 
work gives a characterisation of complexity class PP by using a functional language with 
safe recursion as in Bellantoni and Cook [2]. 

Our system is called iSAPP, which stands for Imperative Static Analyser for Probabilistic 
Polynomial Time. It works on a prototype of imperative programming language based on the 
Loop language |14j . The main purpose of this paper is to present a minimal probabilistic 
polytime certifier for imperative programming languages. 

Following ideas from [5J E] we "type" commands with matrices, while we do not type 
expressions since they have constant size. The underlying idea is that these matrices express 
a series of polynomials bounding the size of stacks, with respect to their input size. The 
algebra on which these matrices and vectors are based is a finite (more or less tropical) 
semi-ring. 



Stacks machines 

We study stacks machines, a generalisation of the classical counters machines. Informally, a 
stacks machine work with letters belonging to a finite alphabet and stacks of letters. Letters 
can be manipulated with operators. Typical alphabet include the binary alphabet {0, 1} or 
the set long int of 64 bits integers. On the later, typical operators are + or *. 

Each machine has a finite number of registers that may hold letters and a finite number 
of stacks that may hold stacks. Tests can be made cither on registers and letters (with 
boolean operators) or to check whether a given stack holds the empty stack. There are 
only bounded (for) loops which are controlled by the size of a given stack. That is, it is 
more alike a f oreach (clement in the stack) loop. Since there are only bounded loops (and 
no while), this de facto limits the language to primitive recursive functions. In this way, 
stack machines are a generalisation of the classical Loop language [13] ■ Since our analysis 
is compositional, we add also functions to the language; their certificates can be computed 
separately and plugged in the right place when a call is performed. 



2.1 Syntax and Semantics 

We denote () the empty stack and (ai . . . a„) the stack with n elements and a\ at top. 

► Definition 1. A stacks machine consists in: 

a finite alphabet £ = {a\, . . . , a n } containing at least two values true and false; 

a finite set of operators, op^, of type S™ — > S, containing at least a 0-ary operator rand, 
operators whose co-domain is {true, false} are predicates noted op?; 

a finite set of registers r and stacks, Sj (the empty stack is noted ()); 
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h and a program written in the following syntax: 

b £ BooleanExp ::=true | false | op?(ei, . . . , e„) | rand() | isempty?(S) 
e 6 Expressions ::=c | r | op(ei, . . . , e n ) | top(S) 

C £ Commands ::=skip | r := e | Si := S 2 | S := (ci . . . c„) | S k := call(/, Si . . . S n ) 

| pop(S) | push(e, S) | C; C | If b Then C Else C | loop S {C} 
f £ Functions ::=def / in (Si . . . S„) {C} out(S.,) 

Note that registers may not appear directly in booleans expressions to avoid dealing 
with the way non-booleans values are interpreted as booleans. However, it is easy to define 
a unary predicate which, e.g. sends true to true and every other letter to false to explicitly 
handle this. 

Expressions always return letters (content of registers) while commands modify the state 
but do not return any value. top( ) does not destruct the stack but simply returns its top 
element while pop( ) remove the top element from the stack but does not return anything. 
It is also possible to assign constant stack to a stack. 

The isempty?() predicate returns true if and only if the stack given in argument holds 
the empty stack and false otherwise. The loopS{C} commands executes C as many time 
as the size of S. Moreover, S may not appear in C. It is, however, possible to make a 
copy beforehand if the content is needed within the loop. Finally, we give the possibility 
to have function call. The command call(/, Si . . . S„) call the function / passing the actual 
arguments Si . . . S„ and finally return the result stored in the stack Sj. 

2.2 Complexity 

The set of operators is not specified and may vary from one stacks machine to another 
(together with the alphabet). This allows for a wide variety of settings parametrised by 
these. Typical alphabets are the binary one ({true, false}), together with classical boolean 
operators (not, and, . . . ); or the set long int of 64 bits integers with a large number of 
operators such as +, *, <, ... Since there is only a finite number of letters and operators all 
have the alphabet as domain and co-domain, there is only a finite number of operators at 
each arity. So, without going deep into details, it makes sense to consider that each operator 
take a constant time to be computed. More precisely, each operator can be computed within 
a time bounded by a constant. Typically, on long int, + can be computed in 64 elementary 
(binary) additions and * takes a bit more operations but is still done in bounded time. 

Thus, in order to simplify the study, we consider that operators are computed in con- 
stant time and we do not need to take individual operators into account when bounding 
complexity. It is sufficient to consider the number of operators. 

The only thing that is unbounded is the size (length) of stacks. Thus, if one want, e.g. to 
handle large integers (larger than the size of the alphabet), one has to encode them within 
stacks. The most obvious ways being the unary representation (a number is represented by 
the size of a stack) and the binary one (a stack of and 1 is interpreted as a binary number 
with least significant bit on top). Obviously, any other base can be use. In each case, addition 
(and multiplication) has to be defined for this representation of "large integers" with the 
tools given by the language (loops). Of course, encoding unbounded value is crucial in order 
to simulate arbitrary Turing Machines (or even simply Ptime ones) and is thus required for 
the completeness part of the result. 

Note that copying a whole stack as a single instruction is a bit unrealistic as it would 
rather takes time proportional to the size of the stack. However, since each stack will 
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individually be bounded in size by a polynomial, this does not hampers the polynomiality of 
the program. A clever implementation of stacks with pointers (i.e. as lists) will also allow 
copy of a whole stack to be implemented as copy of a single pointer, an easy operation. 

Since the language only provides bounded loops whose number of execution can be (dy- 
namically) known before executing them, only primitive recursive functions may be com- 
puted. This may look like a big restriction but actually is quite common within classical ICC 
results on Ptime. Notably, Cobham [5] or Bellantoni and Cook [2] both work on restrictions 
of the primitive recursion scheme; Bonfante, Marion and Moyen [5] split the size analysis 
(quasi-interpretation) from a termination analysis (termination ordering) which also charac- 
terise only primitive recursive programs; and lastly Jones and Kristiansen [9 ], on which this 
work is directly based, use the Loop language which also allows only primitive recursion. 

Since loops are bounded by the size of stacks, it is sufficient to bound the size of stacks in 
order to bound the time complexity of the program. Indeed, if each stack has a size smaller 
than p and the program has never more than k nested loops, then its runtime cannot be 
larger than p k . Similarly, in the original mwp calculus of Jones and Kristiansen, it was 
sufficient to bound the value of stacks in order to bound the runtime of programs (for the 
same reasons) . Note that to have a large number of iterations, one first has to create a stack 
of large size, that is when bounding the number of iterations stacks are considered de facto 
as unary numbers. 

For each stack, we keep the dependencies it has from the other stacks. For example, after 
a copy (Si := S 2 ), the size of Si is the same as the size of S2. Keeping precise dependencies 
is not manageable, so we only keep the shape of the dependence (e.g. the degree with which 
it appear in a polynomial). These shapes are collected in a vector (for each stack) and 
combining all of them gives a matrix certificate expressing the size of the output stacks 
relatively to the size of the input stacks. The matrix calculus we obtain for the certificates 
is compositional. This allows for a modular approach of building certificates. 

3 Algebra 

Before going deeply in explaining our system, we need to present the algebra on which it 
is based. iSAPP is based on a finite algebra of values. The set of scalars is Values = 
{0, L, A, M} and these are ordered in the following way < L < A < At. The idea behind 
these elements is to express how the value of stacks influences the result of an expression. 
expresses no-dependency between stack and result; L (stands for "Linear") expresses that 
the result linearly depends with coefficient 1 from this stack. A (stands for "Additive") 
expresses the idea of generic affine dependency. M (stands for "Multiplicative") expresses 
the idea of generic polynomial dependency. 

We define sum, multiplication and union in our algebra as expressed in Table [T] The 
reader will immediately notice that L + L gives A, while LUL gives L The operator U 
works as a maximum. Over this semi-ring we create a module of matrices, where values 
are elements of Values. We define a partial order < between matrices of the same size as 
component wise ordering. Particular matrices are 0, the one filled with all 0, and I, the 
identity matrix, where elements of the main diagonal are L and all the others are 0. If 
v G Values, a particular vector is V" that is a column vector full of zeros and having v 
at i-th row. Multiplication and addition between matrices work as usualj and we define 
point-wise union between matrices: (A U B)^- = Ajj U Bjj. Notice that A U B < A + B. 



That is: (A + B) itj = A tJ + B it j and (A x B)^ = J^ ^i,h x B 



k,3 
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Table 1 Multiplication, addition and union of values 



As usual, multiplication between a value and a matrix corresponds to multiplying every 
element of the matrix by that value. 

We can now move on and present some new operators and properties of matrices. Given 
a column vector V of dimension n, a matrix A of dimension n x m an index i (i < m), we 
indicate with A(-7a substitution of the z-th column of the matrix A with the vector V. 

Next, we need a closure operator. The "union closure" is the union of all powers of the 
matrix: A u = lj i>0 A 1 . It is always defined because the set of possible matrices is finite. 
We will need also a "merge down" operator. Its use is to propagate the influence of some 
stacks to some other and it is used to correctly detect the influence of stacks controlling 
loops onto stacks modified within the loop (hence, we can also call it "loop correction"). 
The last row and column of the matrix is treated differently because it will be use to handle 
constants and not stacks. In the following, n is size of the vector, k < n and j < n. 

■ (VV°> n ) i = V i 

i if 3p < n, p 7^ k such that V p ^ 
otherwise and V n = 
(V ik ' j ) k = <L otherwise and V„ = L 
I otherwise and V n > A 
t otherwise 



(V^i)i 



if i = n 

iii^j, Vi t^O and V 3 ^0 

otherwise 



In the following we will use a slightly different notation. Given a matrix A and an index 

k, A^ k is the matrix obtained by applying the previous definition of merge down on each 

column of A. Formally, if V is the j-th column of A, then j-th column of A^ k is V* ,J . 

Finally, the last operator that we are going to introduce is the "re-ordering" operator. 

v 

to indicate that the result is a vector whose 



Given a vector V we write 



1 



J 



rows are permuted. The first raw goes in the i-th position and so on till the n-th to the 
j-th. In order to use a short notation, if a row is flowing in its same position, then we don't 



explicit it. Formally, if U 



1 ->• i. 



.,n-*o 



then: U p = J2k V k I k ~> P- 



So, in case two or more rows clash on the same final row, we perform a sum between the 
values. This operator is used for certificate the function calls. Indeed we have to connect 
the formal parameters with the actual parameters. Therefore, we have to permute the result 
of the function in order to keep track where the actual parameters has been substituted in 
place of the formal parameters. 
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4 Multipolynomials and abstraction 

We can now proceed and introduce another fundamental concept for iSAPP: multipolyno- 
mials. This concept was firstly presented in |13j . A multipolynomial represents real bounds 
and its abstraction is a matrix. In the following, we assume that every polynomial have 
positive coefficients and it is in the canonical form. 

First, we need to introduce some operator working on polynomials. 

► Definition 2 (Union of polynomial). Be p, q the canonical form of the polynomials p, q and 
let r,s polynomials, a, /3 natural numbers, we define the operator (p © q) over polynomials 
in the following way: 

max (a, {3) + (r © s) if p = a + r and q = j3 + s. 

(p © q) = \ max (a, fi) • Xi + (r © s) otherwise if p = al t + r and q = /3Xi + s. 
p + q otherwise 

Let's see some example. Suppose we have these two polynomials: X\ + 2X2 + 3X4, X5 
and X\ + 3X2 + SX^X^ + Xq. Call them, respectively p and q. We have that (p © q) is 
X 1 +3X 2 + 3X 4 2 X 5 + X 6 . 

First we need to introduce the concept of abstraction of polynomial. Abstraction gives 
a vector representing the shape of our polynomial and how variables appear inside it. 

► Definition 3 (Abstraction of polynomial). Let p(X) a polynomial over n variables, |~p(A)] 
is a column vector of size n + 1 such that: 

If p(X) is a constant c > 1, then |p(A)] is V^ 

Otherwise if p(X) is a constant or 1, then [~£>(X)] is respectively V° or V„. 
- Otherwise if p(X) is X t , then \p(X)~\ is V|. 

Otherwise if p(X) is aXi (for some constant a > 1), then |~p(A)] is Vf\ 
Otherwise if p(X) is q(X)+r(X), then \p(X)~\ is \q{X)} + fr(X)~|. 
Otherwise, p(X) is q(X) ■ r(X), then \p{X)~\ is M ■ \q(X)~\ U M ■ \r(X)~\. 

Size of vectors is n + 1 because n cells are needed for keeping track of n different variables 
and the last cell is the one associated to constants. We can now introduce multipolynomials 
and their abstraction. 

► Definition 4 (Multipolynomials). A multipolynomial is a tuple of polynomials. Formally 
P = (pi, . . . ,p n )i where each pi is a polynomial. 

In the following, in order to refere to a particular polynomial of a multipolynomial we 
will use an index. So, Pi refers to the i-th polynomial of P. Now that we have introduced 
the definition of multipolynomials, we can go on and present two foundamental operation 
on them: sum and composition. 

► Definition 5 (Sum of multipolynomials). Given two multipolynomials P and Q over the 
same set of variables, we define addition in the following way: (P © Q)i — (Pi © Qi). 

► Definition 6 (Composition of multipolynomial). Given two multipolynomials P and Q 
over the same set of variables, the composition of two multipolynomials is defined as the 
composition component-wise of each polynomial. Formally we define composition in the 
following way: (P • Q) = Qi ■ Pi, . . . , Q n ■ P n . 

Abstracting a multipolynomial naturally gives a matrix where each column is the ab- 
straction of one of the polynomials. 



J.Y. Moyen and P. Parisen Toldin 



► Definition 7. Let P be a multipolynomial, its abstraction \P] is a matrix where the i-th 
column is the vector \Pi\ . 

In the following, we use polynomials to bound size of single stacks. Since handling 
polynomials is too hard (i.e. undecidable), we only keep their abstraction. Similarly, we use 
multipolynomials to bound the size of all the stacks of a program at once. Again, rather 
than handling the multipolynomials, we only work with their abstractions. 



5 Typing and certification 



We presented all the ingredients of iSAPP and we are ready to introduce certifying rules. 
Certifying rules, in figure!!] associate at every command a matrix. We suppose to have n — \ 
stacks. Notice how expressions are not typed; indeed, we don't need to type them because 
their size is fixed. 



n > 1 



h S : = (ci . ..c„) : I<- V„ 



(Const-A) 



(Axiom-Reg) 



h r := e : I 

h Ci : A Vi, (A U ) I , < A 



; (CONST-L) ; 

h S : = (ci) :I(^V' h S := <) : I A V° 

(Push) h d : A h C 2 : B 



h push(e, S;) : I A (V* + V{) 

h C : A A < B 

(Loop) ; — — — — (Subtyp) 



h Ci ; C 2 : A x B 



h loopSfefCi} : (A u ) 4 ' fc h C : B 

bi e BooleanExp h Ci : A h C 2 : B 



h If 6i Then Ci Else C 2 : A U B 



(IfThen) 



h S z := Sj : I 4- V* 
h C : A 



- (CONST-0) 

(Concat) 
(Asgn) 



h skip : I 



(Skip) 



h pop(S) : I 



(Pop) 



def / in (Si . . . S„) {C} out(Sj) : A 
def / in (Si . . . S„) {C} out(Sj) : A 



(Fun) 



S, := call(/,S fc ,.. . ,S P ) : I • 



(1 — » k, . . . , n — > p) 



(FunCall) 



Figure 1 Typing rules for commands and functions 



These matrices tell us about the behaviour of a command and functions. We can think 
about them as certificates. Certificates for commands tell us about the correlation between 
input and output stacks. Each column gives the bound of one output stack while each row 
corresponds to one input stack. Last row and column handle constants. 

As example, command (Skip) tells us that no stack is changed. Concatenation of com- 
mands (Concat) tells us how to find a certificate for a series of commands. The intrinsic 
meaning of matrix multiplication is to "connect" output of the first certificate with input 
of the second. In this way we rewrite outputs of the second certificate respect to inputs of 
the first one. Notice how the rule for (Push) does not have any hypothesis. Indeed, this 
command just increase by +1 (a constant) the size of the stack Sj. When there is a test, 
taking the union (i.e. maximum) of the certificates means taking the worst possible case 
between the two branches. The most interesting type rule is the one concerning the (Loop) 
command. The right premise acts as a guard: an A on the diagonal means that there is 
a stack Si such that iterating the loop a certain number of time results in (the size of) Si 
depending affinely of itself, e.g. |Sj| — 2 x |Sj|. Obviously, iterating this loop may create an 
exponential growth, so we stop the analysis immediately. Next, the union closure used as a 
certificate corresponds to a worst case scenario. We can't know if the loop will be executed 
0,1,2,... times each corresponding to certificates A , A 1 , A 2 , . . . Thus we assume the worst 
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and take the union of these, that is the union closure. Finally, the loop correction (merge 
down) is here to take into account the fact that the result will also depends on the size of 
the stack controlling the loop (i.e. the index k is the number of the variable Sk controlling 
the loop). 

Before start to prove the main theorems, let present some examples using the commands 
call(), loop {}. In the following we will use integer number like 0,1,2,... intending a 
constant list of size 0, 1,2,.. .. This should help the reader. 

► Example 8 (Addition). We are going to present the function + (a shortcut for the following 
function). We can check that the analysis of this function is exactly the one expected. The 
size of the result is the sum of the sizes of the two stacks. 



def addition in (S\,S<2){ 
S3 := 5*2 
loop (5 2 ){ 

push(top(S 3 ),Si) 
pop (S3) 
} 
}aut(Si) 



The associate matrix of this function is ex- 
actly what we are expecting. Indeed, the 



matrix is the following one: 



L 








01 


L 


L 


L 


























L_ 



► Example 9 (Multiplication). In the following we present a way to type multiplication 
between a number and a variable. In the following S2 is multiplied by n and the result is 
stored in £1. 



Si :=0 
loop (S 2 ){ 

} 



typed with 









01 


.4 


L 











L_ 



► Example 10 (Multiplication). In this example we show how to type a multiplication 
between two variables. 



def multiplication in (S^S^H 
S 3 :=0 
loop (S 2 ){ 

S3 := Si + S3 

} 
}out(Si) 



The loop is typed with the matrix 

L M 0" 

L M 

L 

L\ 

So, the entire function is typed with 

L M 0" 



L M 


L 



as is was expected. 



► Example 11 (Subtraction). In this example we show how to type the subtraction between 
two variables. 
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def subtraction in (Si,^)! 
loop (S 2 ){ 
pop (Si) 

} 
}out(5i) 



The function is typed with the identity mat- 
rix I, since the pop() command is typed with 
the identity. 



6 Semantics 

Semantics of the programs generated by the grammar in def [T] is the usual and expected 
one. In the following we are using a as the state function associating to each variable a 
stack and to each register a letter. Semantics for boolean value is labelled with probability 
while semantics for expressions (— > a ) is not carrying anything. In figure El is shown the 
semantic for booleans and expressions. Most of boolean operator have probability 1 and 
operator rand reduced to true or false with probability |. Notice how there is no semantic 
associated to operators opl() and op(). Of course, their semantics depends on how they will 
be implemented. 

Since semantics for boolean is labelled with probability, also semantics of commands 
(—>■") i s labelled with a probability, It tells us the probability to reach a particularly final 
state after having execute a command from a initial state. 



iia(S) = () if a(S)\ = () 



(S,a)->1 true (S,a) 



>l false 



(rand, a) 



1/2 



true 



(rand, a) — K' false 



>a cr(r) 



if a(S) = (a . . . c n ) 
(top(5),cr) -+ a ci 



Figure 2 Semantics of booleans and expressions 

In figure [3] are presented the semantics for commands. Since a compile time all the 
functions definitions can be collected, we suppose that exists a set of defined function called 
Def inedFunctions where all the functions defined belong. 

Since iSAPP is working on stochastic computations, in order to reach soundness and 
completeness respect to PP, we need to define a semantics for distribution of final states. 
We need to introduce some more definitions. Let S> be a distribution of probabilities over 
states. Formally, &i is a function whose type is (Stacks — > Values) — > a. Sometimes we 
will use the following notation £? = {a" 1 , . . . , c"™} indicating that probability of cr, is ojj. 

We can so define semantics for distribution; the most important rules are shown in 
Figure [4] Since semantics for some commands computes with probability equal to 1 , the 
correspondent rule for distributions is not presented. Unions of distributions and multiplic- 
ation between real number and a distribution have the natural meaning. Notice also how 
all the final distributions are normalized distributions. 

Here we can present our first result. 

► Theorem 12. A command C in a state 0\ reduce to another state a-i with probability equal 
to 2>(o-i), where S is the distribution of probabilities over states such that (C, <T\) — ><$ S> '. 



Proof is done by structural induction on derivation tree. It is quite easy to check that 
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<r(S) = << Ci,C 2 , c„ >) cr(S) = (< Ci, . . . , c„ >) 






(Bkip.tr) ->■* <r (p 0p (g) )<T ) _>J -[S/(c 2 ,...,c„)] (push(e,5),<T) ->* <x[S/(e, ci, . . . , c„)] 


(r:= ei.tr) -^ <r[r/ei] (Si :-S a ,°0 ->* <r[S ± /a(S 2 )] (Si := ( 0l , . . . , c„), <r) -►* <t[Si/(ci, . . . , c 


»>] 


def my fun in (Si, ... , S„) {C} out(S m ) £ Def inedFunctions (C, cr[Si, . . . , S n /S]) -+™ cti 




(S p :— call(my/?zn, S), fr) — >" cri 


(Ci,m)->>2 <C 2 ,(T2> ->f 0-3 (bi.cr) ->" true (Ci, <r) ->f cti 




(Ci;Ca,ff) ->"' 3 <r 3 (If &i Then Ci Else C 2 ,o-) ->°" <n 


(S fe , o-) ->■„ () (&i,o-> ->£ false (C 2 ,ct) ->£ trj 




(loop S k {Ci},tr) -> J cr (If &i Then Ci Else C 2 , a) -*■"" <ri 


(Ci.tr) -*? 1 (7i 




(S fe ,tr) -»■„ (ci...c„) (Ci,<7„_i) -»■?» <r n 




(loopS fc {Ci},a) ^? Q ' tr„ 





Figure 3 semantics of commands 



<Ci,<t) -+ 9 & \/cn e @.{c 2 ,CTi) ->@ ^ 




-*® <? 


(Ci;C 2 ,ff) ->•» IJ.^t^)-^ 




C,a) 


(ioo P s fc {cr},^)-*.,^ 1 } /,'" "c /m \L"^' 

(loopS fc {C},<t) -J-® <S 
(l),(T>^true (Ci,<7>->»® (Ca.tr) ->»£ 


(If 6 Then Ci Else C 2 , <r) ->s> (a • 9) U ((1 - a) • S) 



Figure 4 Distributions of output states 
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this property holds, as the rules in Figure [4] are showing us exactly this statement. The 
reader should also not be surprised by this property. Indeed, we are not considering just one 
possible derivation from (C±, <J\) to <72, but all the ones going from the first to the latter. 

7 Soundness 

The language recognised by iSAPP is an imperative language where the iteration schemata 
is restricted and the size of objects (here, stacks) is bounded. These are ingredients of a lot 
of well known ICC polytime systems. There is no surprise that every program certified by 
iSAPP runs in probabilistic polytime. 

Now we can start to present theorems and lemmas of our system. First we will focus on 
multipolynomial properties in order to show that the behaviour of these algebraic constructor 
is similar to the behaviour of matrices in our system. Finally we will link these things 
together to get polytime bound for iSAPP. Here are two fundamental lemmas. Their 
proofs are straightforward. 

► Lemma 13. Let p and q two positive polynomials, then it holds that \p © q\ = \p~\ U \q] . 

Proof, by induction on the size of the two polynomials. By definition the union between 
two polynomial is defined in[2]as the maximum of the comparable monomials. Let's analyze 
the different cases: 

If p = C\ + r and q = c 2 + s. By induction, [r © s] — \r~\ U \s] . By definition pi p © q is 

max (a, ft) + (r © s) and so, by definition [3] the abstraction is defined as [max (a, /3)] + 

\(r © s)] . By using induction hypothesis we get [max (a, /3)] + [r] U [s] . It's clear that 

[max (a, P)~\ is equal to max ([a], [/3]), since the abstraction take in account the value 

of the constants. This is, by definition, the union of the two abstracted polynomials. We 

get, so (\a\ U [/?]) + ([r] U [s]). Notice how the abstractions of the two constants are 

two column vectors having everywhere except for the last row. We can so rewrite the 

previous equation as (\a\ + [r]) U ([/3] + [s]), that is the thesis. 

If p = aXi + r and q = j3Xi + s. This case is very similar to the previous one. 

The last case is where the two polynomials are not comparable. In this case, the union 

is defined as p + q. There are two cases: 

_ If some variables are present just in one polynomial and not in the other one, then 

the correspondent rows, for each single variable, is not influenced by the abstraction 

of the polynomial in which the variable does not appear. 
_ If some variables are present in both. In this case it means that the variables appear 

in at least one monomial with grade gretar than one or in a monomial having more 

than one variable. In both cases the associated abstracted value for both is M. 
The thesis holds. This concludes the proof. 



► Lemma 14. Let P and Q two positive multipolynomials, then it holds that \(P © Q)~\ = 
[P]U[Q1. 

Proof. By definition of sum between multipolynomials [2] we know that sum is defined com- 



ponentwise, (P © Q)i — (Pi © Qi). By lemma 13 we prove the theorem. -4 



► Lemma 15. Let P and Q two positive multipolynomials (over n variables) in canonical 
form, then it holds that \P ■ Q~\ < \Q~\ x \P~\ 
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Proof. We will consider the element in position i,j and so we have: (\Q~\ X \P~\)ij = 
J2k \Q~\i,k x \P~\k,j- We can start by making some algebraic passages: 

\P ■ Q] itj = \P{Q X , ..., Q n )] itj = \PjiQx, ..., Q n )] t 

The equality holds because we are considering the clement in the j'-th column. Since we 
are interested at the element in position z-th we have to understand how the variable Xi (or 
constant) in each Qk is substituted. 

■ Case where i = n + 1 . 

If none of the polynomials Qj, has a constant inside, then the proof is evident, since 
the only possible constant appearing in the result is the possible constant appear- 
ing in Pj. Recall that the element in position (n + l,n + 1) is L by definition, so 
J2k \Q]i,k x \P]k,j contain at least |\P~| n+M . 

Otherwise some constants appear in some Qk- This means that the expected abstrac- 
tion for the clement at position (n + 1, j) may be A or L. If L is the result, then is 
clear that and equality holds, since it means that the constant is 1. The inequality 
hold if the expected result is A, since that on the right side we have to perform the 
following sum: J^k [Q~\ik x \P~]k,j and we could find an A or M value, 
i Case where i < n + 1. In this case we are considering how the variable Xi appears. We 
have four possibilities: 

■ If Xi does not appear in any Q^ polynomials. In this case the expected abstract value 
is 0. Is easy to check that this holds, since on the left side of the inequality we get 
and on the right side we get ^ fe [Q],^ x \P~\k,j that is 0, since all [Q]j,fc are 0. 
In the following we will consider that Xi appears in some Q^ polynomials. Call them 
Qx ■ If some of the polynomials where Xi appears is substituted in some monomial 
of Pj of shape as aX p • q(X) in place of some X p , then for sure on the right side of the 
inequality we will get a value M. On the right side, considering J2k \Q~\i,k x r^ 1 fc,j" 
we will multiply for sure an M value with the abstracted value for Xi of the Q x 
where it appears. The result is so for sure M. 

Otherwise, if some of the polynomials where X t appears is substituted in some monomial 
of Pj of shape as aX p (a > 1), then the expected abstract value depends on how Xi 
appears in Q x .. For all the three possible cases of Xi in Q x . the abstracted value 
obtained on the left side is equal to the value obtained on the right side. 
Otherwise, Xi appears is substituted in some monomial of Pj of shape as X p ; then the 
substitution gives in output exactly the Q x . substituted. The equality holds because 
on the right side we are going to multiply by L the abstracted value found for each 

Qh- 

This concludes the proof. 



Let's now present the results about the probabilistic polytime soundness. The following 
theorem tell us that at each step of execution of a program, size of variables are polynomially 
correlated with size of variables in input. 

► Theorem 16. Given a command C well typed in iSAPP with matrix A, such that 
(C, <7i) — >™ (72 we get that exists a multipolynomial P such that for all stacks Si we have 
that\o- 2 (S i )\<Pi(\a 1 (S 1 )\,...,\a 1 (S n )\) and\P] is A. 
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Proof. By structural induction on typing tree. We will present just the most important 

cases. 

If the last rule is (Const-0), it means that we have only one stack and its size is 0. The 

relative vector in the matrix is a V°. We can choose the constant polynomial 0, whose 

abstraction is exactly V°. The polynomial bounds the size of the stack. 

If the last rule is one of the following (Skip), (Const-A), (Const-L), (Axiom-Reg), 

then the proof is trivial. 

If the last rule is (Push), then we know that the size of of the stack Si has been increased 

by 1. The associated vector is a column vector having L on the i-th row and L on the 

last line. The correspondent polynomial, Xi + 1, is the correct bounding polynomial for 

the i-th stack. 

If the last rule is (Subtyp), then by induction on the hypothesis we can easily find a 

new polynomial bound. 

If the last rule is (Asgn), then we know that the size of the i-th stack is equal to the 

size of the stack j'-th. So, the polynomial bounding the size of the i-th stack uses at least 

two variables and the correct one is P^X^Xj) = Xj. 

If the last rule is (IfThen), then by applying induction hypothesis on the two premises 

we have multipolynomial bounds Q, R such that \Q~\ — A and \R~\ = B. By lemma 

we get the thesis. 
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If the last rule is (Fun), then by applying the induction hypothesis on the premise we 

directly prove the thesis. 

If the last rule is (FunCall), then by applying the induction hypothesis on the premise 

we have a polynomial bound Q such that \Q~\ = A. For all the stacks different from the 

i-th, the bounding polynomial is trivial, while for the stack Si depends on the result of 

the function call. 

The function return the value stored in the j-th stack used inside the function. According 

to the actual parameters, the actual polynomial bound is different from the one retrieving 

by applying the induction hypothesis. 



If last rule is (Concat), then by lemma 15 we can easily conclude the thesis. 

If last rule is (Loop), we arc in the following case; so, A is (B u ) . The typing and the 

associated semantic are the following: 



r-d:B V»,(B U ), M <A 

h loop & {Ci}:(B u ) 



(C u a) 



uUk ( LOOP ) (S k ,a)^a(ci...Cn) (Ci,ff„_i) 



0V, 



(loop S* {d}^) -*"<** o>, 



We consider just the case where n > 0, since the other one is trivial. By induction on the 
premise we have a multipolynomial P bound for command C\ such that its abstraction 
is B. If P is a bound for C\, then P ■ P is a bound for C\\ C\ and (P ■ P) ■ P is a bound 
for C\\C\\C\ and so on. All of these are multipolynomial because we are composing 
multipolynomials with multipolynomials. 



By lemma 15 and knowing that \F\ is B we can easily deduce to have a multipolynomial 
bound for every iteration of command C\. In particularly by lemma [14] we can easily sum 
up everything and find out a multipolynomial Q such that \Q~\ is B u . This means that 
further iterations of sum of powers of P will not change the abstraction of the result. 
So, for every iteration of command C± we have a multipolynomial bound whose abstrac- 
tion cannot be greater than B u . So, we study the worst case; we analyse the matrix 
B u . 



14 iSAPP, a complete polytime complexity verifier tool for PP. 



Side condition on (Loop) rule tells us to check elements on the main diagonal. Recall 
that by definition of union closure, elements on the main diagonal are supposed to be 
greater then 0. We required also to be less then A. Let's analyse all the possibilities of 
an element in position i,i: 
_ Value means no dependencies. If value is L it means that Qi concrete bound for 

such column has shape Si + r(S), where Si does not appear in r(S). Iteration of such 

assignment gives us polynomial bound increment of the value of variable Si . 

If value is A could means that Qi concrete bound for such column has shape aSi + r(S) 

(for some a > 1), where Si does not appear in r(S). Iteration of such assignment lead 

us to exponential blow up on the size of Si. 

Otherwise value is M. This case is worse than the previous one. It's evident that we 

could have exponential blow up on the size of Si. 
The abstract bound B is still not a correct abstract bound for the loop because loop 
iteration depends on some variable Sk- We need to adjust our bound in order to keep 
track of the influence of variable Sk on loop iteration. 

We take multipolynomial Q because we know that further iterations of the algorithm 
explained before will not change its abstraction \Q~\ . Looking at i-th polynomial of 
multipolynomial Q we could have three different cases. We behave in the following way: 
_ The polynomial has shape Si + p(S). In this case we multiply the polynomial p by 

Sk because this is the result of iteration. We substitute the i-th polynomial with the 

canonical form of polynomial Si + p(S) ■ Sk- 

The polynomial has shape Si + a, for some constant a. In this case we substitute 

with Si + a ■ Sk- 
- The polynomial has shape Si or Si does not appear in the polynomial. We leave as 

is. 
In this way we generate a new multipolynomial, call it R. The reader should easily 
check that these new multipolynomial expresses a good bound of iterating Q a number 
of times equal to Sk- Should also be quite easy to check that \R~\ is exactly (B u ) . This 
concludes the proof. 

■4 

Polynomial bound on size of stacks is not enough; we should also prove polynomiality 
of number of steps. Since all the programs generated by the language terminate and all the 
stacks are polynomially bounded in their size, the theorem follows straightforward. 

► Theorem 17. Let C be a command well typed in iSAPP and a\,a n state functions. If 
■n : (Ci,cro) ~^c a n, then there is a polynomial p such that \ir\ is bounded by p(J^ |(7o(Si)|). 

Proof. By induction on the associated semantic proof tree. -4 



7.1 Probabilistic Polynomial Soundness 



Nothing has been said about probabilistic polynomial soundness. Theorems 16 and 17 tell 
us just about polytime soundness. Probabilistic part is now introduced. We will prove prob- 
abilistic polynomial soundness following idea in [5], by using "representability by majority". 

► Definition 18 (Representability by majority). Let ao[S/n] define as WS,ao(S) = n. Then 
C is said to represent-by-majority a language L C N iff: 

1. If n 6 L and (C,ao[S/n]) ->@ 9, then 9{<j ) > E„ l>0 ^K0; 

2. liniL and (C,a^[S/n\) ^® ®, then £ m>0 ®{<j m ) > @(a ). 
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Observe that every command C in iSAPP represents by majority a language as denned 



in 



18 In literature [T] is well known that we can define PP by majority. We say that the 
probability error should be at most \ when we are considering string in the language and 
strictly smaller than ^ when the string is not in the language. So we can easily conclude 
that iSAPP is sound also respect to probabilistic polytime. 

8 Probabilistic Polynomial Completeness 

There are several way to demonstrate completeness respect to some complexity class. We 
will show that by using language recognised by our system we are able to encode Probabilistic 
Turing Machines (PTM) . We will are not able to encode all possible PTMs but all the ones 
with particularly shape. This lead us to reach extensional completeness. For every problem 
in PP there is at least an algorithm solving that problem that is recognised by iSAPP. 

A Probabilistic Turing Machine [7] can be seen as non deterministic TM with one tape 
where at each iteration are able to flip a coin and choose between two possible transition 
functions to apply. 

In order to encode Probabilistic Turing Machines we will proceed with the following 
steps: 
i We show that we are able to encode polynomials. In this way we are able to encode the 

polynomial representing the number of steps required by the machine to complete. 
h We encode the input tape of the machine. 
■■ We show how to encode the transition 5 function. 

We put all together and we have an encoding of a PTM running in polytime. 

Should be quite obvious that we can encode polynomials in iSAPP. Grammar and 
examples [8] [9] [10] [IT] give us how encode polynomials. 

We need to encode the tape of our PTMs. We subdivide our tape in three sub-tapes. 
The left part tape ; , the head tape ?1 and the right part tape r . tape r is encoded right to 
left, while the left part is encoded as usual left to right. 

Let's move on and present the encoding of transition function of PTMs. Transition 
function of PTMs, denoted with S, is a relation S C (Q x E) x (Q x £ x {«— ,4-, — >}). Given 
an input state and a symbol it may give in output more tuples of state, a symbol and a 
direction of the head (left, no movement, right). 

In the following we are going to present two procedures to encode movements of the 
head. It is really important to pay attention on how we encode this operations. Recall that 
a PTM loops the S function and our system requires that the matrix certifying/typing the 
loop needs to have values of the diagonal less than A. 

► Definition 19 (Move head to right). Moving head to right means to concatenate the bit 
pointed by the head to the left part of the tape; therefore we need to retrieve the first bit of 
the right part of the tape and associate it to the head. Procedure is presented as algorithm 
[l] call it MoveToRightQ. 

The first column of the matrix represents dependencies for variables tape; , the second 
represents tape /i; third is tape r , forth is M s t a te and finally recall that last column is for 
constants. In the following, columns of matrices are ordered in this way. 

Similarly we can encode the procedure for moving the head to left and the possibility 
of not moving at all, that is a skip command. So, the S function is then encoded in the 
standard way by having nested If-Then-Else commands, checking the value of rand, the 
state, the symbol on a tape and performing the right procedure. 
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Algorithm 1 Move head to right 



push(top(tape ?l ) , tape ; ) 
tape^ := () 

push(top(tape r ),tape ft ) 
pop(tape r ) 



Using typing rules we are able to type the 
algorithm with the following matrix: 



L 0' 



L 

L 

L A L 



Algorithm 2 Prototype of encoded S function 



if rand then 

if equal?(M sta te, 1) then 
else 

if equal?(M sta te,2) then 

else 

end if 
end if 
else 

end if 



The prototype is created by nesting 
If-Then-Else commands and checking the 
state of the machine, for each branch, then, 
an operation of moving the head is per- 
formed. Notice that since three possible 
operations could be performed, all the nested 
If-Then-Else are typed with the following 
matrix: 



L 



































L 

















L 





L 


A 


L 





L 
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Every matrix could be seen as adjacency matrix of a graph 
As example, the following matrix A: 



L 








01 


L 


L 


L 





L 














M 


L 


L_ 



has its own representation in the graph on 
the right side. 

Figure 5 Example of graph representing a matrix in iSAPP 




Finally, we have to put the encoded 5- function inside a loop. The machine runs in a 
polynomial number of steps. Since the encoded (^-function is typed with the matrix presented 
in Alg. [2] we can easily see that the union closure of that matrix fits the constraints of the 
typing rule of loop {}. We can therefore conclude that we can encode Probabilistic Turing 
Machine working in polytimc. 

9 Polynomiality 

In this last session we will discuss why iSAPP is a feasible analyser. We already shown 
that is sound, so is able to understand whenever a program does not run in Probabilistic 
Polynomial Time. Moreover, is also complete, respect to PP; this means that iSAPP is 
able to recognise a lot of programs. At least one for each problem in PP. The final question 
has to do with the efficiency of our system: "how much time does it take iSAPP to check 
a program?". Can be shown that iSAPP is running in polytime respect to the number of 
variables used. 

Since the typing rules are deterministic, the key problems lays on the rule (Loop). 



h-Ci : A 



V*, (A L 



< A 



(Loop) 



h looped} :(A u ) 4fe 

It is not trivial to understand how much it takes a union closure to be performed. While 
all the typing rules for all the other commands and expressions are trivial, the one for loop 
needs some more explanations. By definition, A u is defined as U^A 1 . 

In the example in Figure [5] we can easily check that C flows in S\ with M in one step. 
So, A 2 have M in position (4, 1), (4, 2), (4, 3). Indeed, by using the rule of our algebra we 
can see how dependencies flows in the graph. 

How many unions have to be performed in order to calculate U^A*? In order to answer 
to this question, we can prove the following theorem. 

► Theorem 20 (Polynomiality). Given a squared matrix A of size n and B = (J. A 1 , we get 

that B = Ui<n 2 A' '■ Union closure can be calculated by considering just the first n 2 matrix 
power. 

Proof. Here is the scratch of the proof. Since the matrix is an encoding of a flow graph, we 
can see the matrix as a graph of dependencies between stacks size. Recall that the union 
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is component-wise, so we can focus on a singular element of a matrix. Given two nodes Si 

and S2 of our graph, let's check all the possibilities: 

The expected value is M. If so, after no more than n iteration of A we should have 
found it. If not, there are no possibilities to have M in that position. After n iteration, 
the information has flown through all the nodes. 

i The expected value is A. We need to iterate more than n times. Indeed A value can be 
found also by adding L + L. In the flow-graph relation, this means finding two distinct 
paths from node S± to S2. This can be easily done by encoding two paths in one. By 
generating all the possible pairs of nodes, we can easily see that the number of steps to 
find, if exists, two distinct paths takes n 2 number of steps (number of all pairs). 

If after n 2 steps no M or A value has been found, the maximum value found is the 
correct one. Indeed, if no dependence has been found or if just a linear dependence has 
been found, no further iteration could change the final value. 

10 Conclusions 

We presented an ICC system characterising the class PP. There are several improvements 
respect to the known systems in literature. We can catalogue them in two sets. First, 
we extend the known system to probabilistic computations, being able to characterise PP. 
Since the typing requires polynomial time, it is feasible to use iSAPP as a static analyser for 
complexity The typing/certificate gives also information about the polynomial bound. On 
the other hand, respect to sequential computations, we presented a finer analysis. iSAPP 
works over a concrete language and takes care of constants and function calls. For all of 
these reasons, we are able to show a program that cannot be typed correctly by Kristiansen 
and Jones [5]. 

Algorithm 3 Example of recognised program 

loop (Si){ That is typed with the identity matrix I •<— 

5*2 :— * S2 V°. For multiplication we use the implc- 

} mentation in def |9] 



Since every constant is abstracted as a variable in [S] , they cannot for sure recognise that 
this program runs in polytime and for this reason this program should be rejected. Once 
abstracted it is impossible to know the value of the constant. Of course, everything depends 
on how the abstraction is made. In general, every program which deals with constants 
could appear problematic in [3] [3J; At least, for a lot of programs, their bounds are bigger. 
Moreover, as they wrote in [3J: "Note that no procedure for inferring complexity will be 
complete for L concret e\ while our procedure is sound and complete for our concrete language. 

Finally we would like to point out some future direction: 
1 Integrating the analysis with new features in order to capture more programs. 

Apply our analysis to a more generic imperative programming language. 

1 Extending the algebra in such way that the associated certificates would tell more detailed 
information about the polynomial bounding the complexity. 

h Make a finer analysis in order to be sound and complete for BPP. 
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